% !TEX root =  main.tex

\subsection{ModelSec}
\label{sec:ModelSec}
\begin{figure}[t]
	\centering
	\includegraphics[width=\columnwidth]{./figures/ModelSec}
	\caption{ModelSec Y-Process}
	\label{fig:ModelSec}
\end{figure}

S\'anchez \etal proposed \textsl{ModelSec} \cite{sanchez:jucs-15-15} as a generative architecture for \mds, following \mda pattern.

\smallskip\noindent \textbf{Security Concerns.}\hspace{1cm} \textsl{ModelSec} supports the definition of requirements as a catalog from which models can be derived. 

It is designed to model and analyze multiple security concerns in one security model, 
including \emph{privacy, integrity, access control, authentication, availability, non-repudiation} and \emph{auditing}.

\smallskip\noindent \textbf{Modeling.}\hspace{1cm} 
\emph{ModelSec} first proposed a core \emph{requirements metamodel} as a reference model for requirements meta-modeling. Then functional requirement model and security requirement model
can be extended from the general requirements metamodel by integrating business concepts and security concepts respectively.
Due to generality, the authors proposed an extended security requirement model by integrating seven categories of security concerns, \eg privacy, integrity, access control, \etc.

Different from profiling UML, \emph{ModelSec} provides a tailored \dsl for modeling security concerns, called \emph{SecML} (Security Modeling Language).
Since both functional requirement model and security requirement model are inherited from general requirement metamodel, the \emph{SecML} can be also used to specify system functions.

The authors did not explain clearly how to integrate security model with functional model except some mappings from security decisions to data resources in the security design model later after,
which is a weak conformance to the model integration feature in the Y-Model.

\smallskip\noindent \textbf{Transformations.}\hspace{1cm} The security requirement model (the same to the functional requirement model) can be transformed to security design model by mapping each requirement
to an instance of a certain meta-class in the security design model with decision attributes, including platform specific information (conforming perfectly to the \mda paradigm).

However, in the final model-to-code transformation, only XACML policies and Oracle PL/SQL script are auto-generated that lacks of system infrastructure.

\medskip
\smallskip\noindent \textbf{Analysis.}\hspace{1cm} 
The security analysis is performed informally on security design model, which is another drawback of \emph{ModelSec}.
Traceability is not considered according to the authors' work.

In summary, despite of its weak conformance to the Y-Model, we can still
synthesize \emph{ModelSec} as \emph{Y-Process} as can be seen in \fig
\ref{fig:ModelSec}.





